Asset and liability modeling tool

ABSTRACT

A method for modeling financial variables describing a client over a time period. The method may comprise the step of generating a first simulation of the time period. Generating the first simulation may comprise the steps of assigning the client to a first health-related state and advancing the first simulation from a first interval of the time period to a second interval of the time period. A probability that the client will transition from the first health-related state to a second health-related state may be calculated, the client may be randomly assigned to either the first health-related state or the second health-related state considering the probability. According to various embodiments, the methods may also comprise the steps of calculating a client income for the second interval; and calculating a plurality of client expenses for the second interval. Also, the various health-related states may include one or more of a healthy state, a long term care (LTC) state, a disabled state and a dead state.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of U.S. application Ser. No.11/389,962 filed on Mar. 27, 2006.

STATEMENT UNDER 37 C.F.R. §1.84(a)(2)

The patent or application file contains at least one drawing executed incolor. Copies of this patent or patent application publication withcolor drawings will be provided by the Office upon request and paymentof the necessary fee.

BACKGROUND

There is a present need in asset management to move towards“liability-led investing” at the individual and/or household level.Currently, there is an observable trend for governments and corporationsto push the responsibility for pension and healthcare liabilitymanagement and financing back to the individual because existingarrangements for their funding are either unaffordable or the financingrisk is too high. Consequently, it has become increasingly important forindividuals to accurately model their financial condition into thefuture in order to plan for multiple goals such as retirement, collegeeducation for children, etc.

Such modeling is a challenging task. Most individuals have multiplefuture goals, some flexibility in the timing and acceptable spend ofthose future goals (e.g., they can retire earlier or later; retire on ahigher or lower retirement income) and dynamic goal priorities (e.g.,will trade-off goals differently depending on the likely level ofspend). Dependencies between these goals go forwards and backwards intime. For example, if an individual (or household) spends more on theirchildren's education, he or she will have less to support retirement. Onthe other hand, if the individual retires later, he or she may be ableto afford to spend more on their children's education today.

On top of this wide array of goals and related choices, individuals (andhouseholds) face uncertainty about their future income, future expenses,and even how long they are going to live. For example, there isuncertainty about an individual's future earned income, social securityreceipts, Medicare benefits and returns on their savings andinvestments. There is also uncertainty about an individual's futureexpenditures on healthcare, nursing care, residential care, etc. Thereis a risk the individual may die young. Under those circumstances, theywant to be sure their family is provided for. There is also a risk theindividual may live a long time. In that case, they want to be sure thatthey have enough assets to support them through a very long retirement,where healthcare costs may be high.

When considering assets, liabilities, goals, and the uncertainties oflife, people care about every outcome. There are, however, too manyvariables for any individual, no matter how intelligent, to solve theproblem in all of its complexities and find comprehensive answers. Mostindividuals solve the problem serially. For example, if they have enoughmoney, they will send their children to a particular school without athorough understanding of how that would affect their retirement age orspend, or how it would impact their family if they were to dieunexpectedly.

There are existing tools for modeling an individual's financialsituation, however, they do not fully address the problem. In general,existing tools focus on funding individual goals and ignore theinteractions and time dependencies between cashflows and theirpriorities. They ignore unforeseen events such as health events or theneed for long-term care. These existing tools assume that the only riskdecision to be made by the individual is how much risk to take in theinvestment portfolio. They therefore focus the individual on expectedportfolio returns, or the degree of investment risk needed to meet thatsingle goal. They do not help the individual assess the nature of therisks to their meeting their set of goals, nor help them understand thenature and consequences of the choices they have, of which investmentrisk is but one.

BRIEF SUMMARY OF THE INVENTION

In one general aspect, the present invention is directed to a method fordisplaying the results of a financial model to allow visual assessmentof a client's future financial condition in an interactive, timelycontent-rich manner. The financial model may be generated by a financialmodeling tool that captures a comprehensive set of future financialvariables for the individual (e.g., cashflows, liabilities etc.), andthe uncertainty and range of possible outcomes for each. The financialmodel is displayed in a manner that provides a way of visualizing thepossible outcomes that enable the individual to understand that range,and understand the consequences on the outcomes of different choicesthey have. In so doing, the model may focus individuals on riskmanagement with respect to their future goals, not simply on investmentreturns. In addition, the financial model, in various embodiments, maymake financial advising more attractive to individuals by allowing forthe generation of an approximate model based on abbreviated input data,for example, a set of input data that may be entered on a single screen.The abbreviated input model enables the individual to provide accurateinput data whilst engaged in reviewing the results, as opposed toproviding comprehensive input data prior to reviewing the output. Thismay provide an incentive for individuals to engage in the often complexand time consuming process of creating a full financial model.

The financial model models the client's future financial condition overa given time period (e.g., a life, the life of a household, etc.) bygenerating a likely range of forecasted values over the time period forone or more financial variables describing the client. Exemplaryfinancial variables include, net worth, liquid assets, investableassets, outflow, annual cashflow, available net worth (i.e., balancesheet and cashflow items), etc. In various embodiments, the financialmodel may include a number of computer simulations of the time period.Each computer simulation may generate a set of possible forecastedvalues for the financial variable or variables over the time period. Theaggregate of the sets of values from all of the simulations forms theresults of the financial model (e.g., a distribution of possibleoutcomes for the client).

The results of the financial model may be displayed as a graphicalrepresentation, which may display results for some or all of the modeledfinancial variables so that the client can gain a visual understandingof their prospective financial condition and gain insight as to theconsequences of different available choices. The graphicalrepresentation may take the form of a topographical chart positioned ona plane defined by a time axis and a value axis, such that values of thefinancial variables over time may be plotted on the time and value axis.Each coordinate set on the axes may correspond to a point on thetopographical chart. The height of the points on the topographical chartindicates the likelihood that the displayed financial variable will takethe value and time indicated by the corresponding coordinate sets. Forexample, the height of the points may indicate the number of simulationsthat result in a value and time of the displayed financial variable orvariables represented by the corresponding coordinate set. In variousembodiments, the color of points on the topographical chart alsoindicates the likelihood that the displayed financial variable will takethe value and time of the corresponding coordinate sets (e.g., how manyof the simulations result in the corresponding coordinate sets). Forexample, more intense colors may indicate a larger portion of thesimulations. In that way, the height, color, and intensity of points onthe topographical chart may be indicative of the probability that theforecasted variables will have the value and time of the correspondingcoordinate sets. The color of points on the topographical chart may alsoindicate whether the represented value of the financial variable ispositive or negative. For example, negative values of the financialvariable or variables (e.g., values indicating that the client will lackfinancial means) may be red while positive values may be green.

The graphical representation may also comprise representations of one ormore goals of the client at a point or points in time. Each goal mayrepresent an expenditure or other financial event that the client wouldlike to achieve in the future. Each representation indicates a portionof the simulations where the goal is achieved. Also, selecting therepresentation of the goal may allow detailed information about the goalto be viewed and/or edited. Where the goal is a retirement goal, thetime after retirement may be partitioned into a plurality of timeblocks. The success of the retirement goal, (e.g., whether the clienthas enough assets and/or income to meet desired consumption levels) maybe indicated for each time block. The user may be able to drag a goal onthe topographical chart so as to adjust the time horizon for the goal.The simulations may be accordingly regenerated to determine thelikelihood of achieving the goal given the revised horizon. The user mayalso be able to analyze the graphical representation. For example,placing a cursor over the representation at various points in time maydisplay information over the various simulations (e.g., the distributionof possible outcomes at that point in time, states of the client, etc.)In various embodiments, the user may manipulate the viewing angle of thegraphical representation using navigation buttons.

In another general aspect, the present invention may be directed to amethod for modeling financial variables describing a client over a timeperiod. The method may comprise the step of generating a firstsimulation of the time period. Generating the first simulation maycomprise the steps of assigning the client to a first health-relatedstate and advancing the first simulation from a first interval of thetime period to a second interval of the time period. A probability thatthe client will transition from the first health-related state to asecond health-related state may be calculated, the client may berandomly assigned to either the first health-related state or the secondhealth-related state considering the probability. According to variousembodiments, the methods may also comprise the steps of calculating aclient income for the second interval; and calculating a plurality ofclient expenses for the second interval. Also, the varioushealth-related states may include one or more of a healthy state, a longterm care (LTC) state, a disabled state and a dead state.

In yet another general aspect, the present invention may be directed tomethods of simulating the finances of a client over a time period. Themethods may comprise the step of receiving a description of a firstgoal. The description of the first goal may comprise a priority of thefirst goal, a date for the first goal, a minimum amount for the firstgoal and a desired amount for the first goal. The methods may alsocomprise the step of receiving a description of a second goal, which mayalso comprise a date for the second goal, a minimum amount for the firstgoal a desired amount for the second goal, and a priority of the secondgoal, which may be lower than that of the first goal. The client incomeand expenses over a first interval of the time period may be calculated,with the client expenses categorized into discretionary andnon-discretionary expenses. The non-discretionary expenses may be fundedwith at least a portion of the client income. If any client incomeremains, at least a portion of the remaining client income may beallocated to a first goal account and a second goal account. Thisallocating may comprise the steps of assigning a minimum amount to thefirst goal account; if any client income remains, assigning a minimumamount to the second goal account; and if any client income remains,assigning a desired amount to the first goal account.

The user of the financial modeling tool may be the client itself (e.g.,a business entity, individual, or household), or in various embodiments,may be a financial advisor or other representative working on behalf ofthe client.

BRIEF DESCRIPTION OF THE FIGURES

Embodiments of the present invention are described herein, by way ofexample, in conjunction with the following figures, wherein:

FIG. 1 shows a block diagram of a system for implementing a financialmodeling tool;

FIG. 1A shows an exemplary workflow for use with a financial modelingtool;

FIGS. 2-46 depict screen shots of user interfaces provided by afinancial modeling tool according to various embodiments of the presentinvention;

FIG. 47 shows an exemplary process flow for use with a financialmodeling tool; and

FIGS. 48 and 49 show exemplary state diagrams for use with a financialmodeling tool.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the present invention are directed in general to afinancial modeling software tool that allows a user to generate afinancial model of the possible future financial condition of anindividual or household (e.g., a client) based on current data andassumptions about the future. The financial model models the clients'future financial condition by forecasting the values of one or morefinancial variables such as, for example, net worth, liquid assets,investable assets, outflow, annual cashflow, available net worth, etc.The model may be generated using any suitable modeling method or methodsfor simulating asset returns and stochastic liabilities (e.g., a MonteCarlo method) and may be based on input data and assumptions specific tothe client. Results of the model may be presented to a user of thefinancial modeling tool and/or clients in a visual, interactive andcontent-rich manner. For example, the results may be displayed on atopographical chart, as shown in FIG. 32, where the height of each pointon the chart indicates the probability that a displayed financialvariable or variables will have the value and time indicated bycoordinates of the point (e.g., the height at a point corresponding to amillion dollars at a given time in the future may indicate thelikelihood that the client's net worth will be one million dollars atthe given time). Before detailing screen shots of an exemplary userinterface allowing the user to input data and set future assumptions,and before detailing the visual, interactive output, a few words areneeded about the environment and workflow in which the system may beused.

FIG. 1 shows a diagram of a computer system 110 for implementing afinancial modeling software tool 100 according to various embodiments ofthe present invention. The system 110 includes a server 106 incommunication with one or more user machines 102 via a network 104,which may be any suitable wired or wireless communication networkincluding, for example, a LAN or a WAN. The financial modeling tool 100,may be a software program executed by the server 106, and may include aplan module 108 and a simulation module 112. The plan module 108 mayprovide one or more user interfaces that allow a user of the tool 100 toenter input data that is used as input to develop the model. In variousembodiments, the plan module 108 may provide the user interfaces to theuser machines 102, prompting the user to enter the input information,for example, interfaces 600, 300, and 700 described below.

Various input data for developing the model may be stored in databases114, 116, 118, 120. The input data may be received from a user, forexample, via plan module 108, or may be received from an outside source,such as a subscription service, etc. Plan database 118 may storefinancial information about the client including, for example, income,asset, and liability information. The plan database 118 may also storegoal information for the client, as described in more detail below. Invarious embodiments, the plan database 118 may include data about aclient entered through the plan module 108 in a current or previoussession, as well as generic or stock data that may be applied tomultiple clients. Assumption database 116 may include data describingassumptions that may be used when developing the model. Exemplaryassumption data includes, the loss tolerance of the client (e.g., theclient's tolerance for one year losses on their investment portfolio),the tax status of the client, the transaction costs for buying andselling assets, etc. Other examples of assumption data may includeactuary tables or other data for modeling states of the client (e.g.,date of death, disability state, etc.). Assumption data may be enteredthrough the plan module 108 or may be default data that may be appliedto multiple clients, such as, for example, default transaction costs,default retirement consumption adjustments, etc.

An economic database 114 may include data describing historical economicperformance that may be considered in generating the model. For example,the database 114 may include data describing the historic trends of thestock market, interest rates and the related expected asset returns,volatilities and covariances, etc. Regulation database 120 may includeinformation describing various laws and regulations that may affect themodel including, for example, tax codes, securities laws andregulations, etc. Data stored at the economic and regulation databases114, 120 may be received from one or more data subscription services.

The simulation module 112 may model the possible range of the client'sforecasted financial condition over the chosen time period consideringthe input data stored in databases 114, 116, 118, 120. The time periodmay be, for example, the client's expected life. In various embodiments,the simulation module 112 may model the range of the client's forecastedfinancial condition according to a Monte Carlo technique, for example,by simulating both asset returns and stochastic liabilities, in thecontext of desired future cashflows (e.g., the amounts required for theclient to meet future goals and expenses). For each simulation, thesimulation module 112 may generate output values for the financialvariables over one instance of the time period, considering the inputdata, assumptions and other constraints.

In various embodiments, each simulation may generate values of thefinancial variables based on assumptions regarding states of the client,and/or the economy at large. For example, each simulation may generate adate of the client's death; whether and, if so, when the clientexperiences a disability; whether and, if so, when the client requireslong term care; etc. Each simulation may also assume future economictrends regarding, for example, the stock market, interest rates, etc.The states assumed by any particular simulation may be randomlygenerated, but based on the likelihood of the states occurring, forexample, as shown by actuary tables, assumptions, or other inputdata/constraints. For example, if the statistical data indicates thatthere is a 5% chance that the client will experience a disability at age40 and a 10% chance that the client will experience a disability at age50, then approximately 5% of the total number of simulations may assumea disability at age 40 and approximately 10% will assume a disability atage 50.

It will be appreciated that, in various embodiments, the values for thefinancial variables generated during each simulation may reflect thedependency and/or covariance of the financial variables on each other.For example, the values for asset returns, interest rates and inflationrates generated by any given simulation may allow for the historicco-variance of those variables. Also, the simulations may generatevalues of future earned income that covary with the financial variablesrepresenting economic state and inflation rates. In addition, eachsimulation may model actuarial co-variances (e.g., a differentlikelihood of needing long-term care if disabled; different lifeexpectancy depending on health status).

The aggregate of the sets of values from all of the simulations may bedisplayed to the user and/or the client as a topographical chart orother graphical representation, for example, shown by user interfaces900 and 1000 of FIGS. 32-46 and described in more detail below. Thetopographical chart may show results for one financial variable at atime, or may show results for numerous financial variablessimultaneously.

It will be appreciated that in various embodiments, some or all of thesoftware program of the financial modeling tool 100 may be executed bycomponents of the network 110 other than the server 106. For example,user machines 102 may contain some or all of the software of thefinancial modeling tool 100. In such embodiments, the user machines 102may access the databases 114, 116, 118, 120 via server 106, or may, invarious embodiments, each include local copies of the databases 114,116, 118, 120. It will also be appreciated that the databases 114, 116,118, 120 may be implemented using any number of physical or logicalstorage devices.

FIG. 1A shows an exemplary workflow 200 of the financial modeling tool100 according to various embodiments. At box 202, the tool 100 mayreceive information about the client that will be the subject of themodel. The information may include information about an individualclient, or information about the client's household including, forexample, a spouse or other co-client and children. An exemplary userinterface 600 for receiving the client information is shown in FIGS. 2-5as described below.

From step 202, the client, and/or the user of the financial modelingtool 100, may choose to enter an abbreviated plan at box 204 or a fullplan at box 206. Entering a full plan at box 206 may include enteringdetailed plan and assumption information about the client including theclient's income, assets, liabilities, goals, etc., for example, at userinterface 700 shown at FIGS. 7-31. It will be appreciated that enteringa full plan may be complex and time consuming. Accordingly, the clientand/or user may alternatively enter an abbreviated plan at box 204 thatmay include less information or less detailed information about theclient than is entered in a full plan. An exemplary user interface 300for receiving an abbreviated plan is shown below in FIG. 5. When anabbreviated plan is received, data for generating the outcomes may becollected from the client in a single screen, rather than requiring theuser to enter information at multiple screens. The plan module 108and/or the simulation module 112 may supplement the abbreviated plan byestimating additional information needed to run the simulations.

At step 208, the simulation module 112 may run one or a series ofsimulations of the client's life based on the information received atsteps 202, 204 and/or 206. Results of the simulations may be displayedat box 210, for example, as one or more of the graphical representationsshown at interface 900 in FIGS. 32-46. It will be appreciated thatsimulations run based on full plans may generate more accurate resultsthan those run based on abbreviated plans. It will also be appreciatedthat even some full plans can be made to result in more accuratesimulations by entering additional and/or more accurate information. Forexample, if the client and/or user enters a full plan at box 206, butdoes not enter a particular set of assets, then the accuracy of theresulting simulations will suffer. Accordingly, when the results of thesimulations are shown at box 210, the user and/or client may have theoption of creating or supplementing a full plan at box 206. The new fullplan may then be used by the simulation module 112 to generate moreaccurate simulations.

Clients are sometimes reluctant to enter or provide a user (e.g., afinancial analyst) with enough financial and/or personal information forthe simulation module 112 to generate its most accurate simulations. Forone thing, gathering and entering the sheer volume of desirableinformation may take a long time. For another, the client may behesitant to provide detailed information to a financial analyst withwhom they may not have an established relationship, or who may notmanage all of their assets. Accordingly, the financial modeling tool 100may be used to motivate the client to disclose and/or enter as muchinformation as possible. For example, the client may enter and/ordisclose to a user only the information necessary for an abbreviatedplan. Based on the outcomes of the simulations from the abbreviatedplan, however, the client may become quickly engaged by the resultinggraphical representation of the output and may be more motivated toprovide additional and/or more accurate information as required tofurther understand the impacts on the output. It will be appreciatedthat subsequent outputs and graphical representations based on theadditional and/or more accurate information may themselves be moreaccurate. The client and/or the user may then begin to create orsupplement a full plan by entering the additional data and re-runningthe financial model. In this way, the financial modeling tool 100 maymove away from the linear logic of requiring a client to provide and/orenter all input information before the client can become engaged in themodel's output.

FIGS. 2-31 show embodiments of user interfaces 600, 300, 700 that may beprovided to the user, for example, by the plan module 108 according tovarious embodiments to allow the user, at user machine 102, to enterinput data about the client's assets and liabilities as well as futuregoals and other assumptions and constraints regarding the future. Theinput data entered through the user interfaces may then be considered bythe simulation module 112 to generate models of the client's futurefinancial condition, as discussed herein. Each of the interfaces 600,300, 700 includes a navigation toolbar 602 and navigation buttons 612,614 that may allow the user to navigate between the various screens.Toolbar 602 includes buttons or tabs that may allow the user to jumpbetween various screens of the interfaces 600, 300, and 700. It will beappreciated that various interfaces 600, 300, 700 or screens therein maynot function until prerequisite information has been entered at anotherscreen and/or prerequisite calculations have been performed. Forexample, it may not be possible to enter a qualified employeecontribution income type, as shown at FIG. 15, until a qualified assethas been added to receive the contribution, as shown at FIG. 9.

FIGS. 2-4 show embodiments of the user interface 600, according tovarious embodiments that may be provided to the user, for example, toprompt the user to enter and/or edit information about the client whowill be the subject of the financial modeling tool 100. Again, asmentioned above, the user may be the client itself, or may be afinancial advisor or some other representative of the client. Theinterface 600 includes an additional toolbar 604 having buttons or tabs605, 607, 609 corresponding to different screens within the userinterface 600. Selecting one of the buttons or tabs 605, 607, 609 causesthe corresponding screen to appear. In FIG. 2, the Select Client button605 has been selected, allowing the user to select an existing client,or create a new client. Field 608 allows the user to search existingclients by various criteria including, for example, recently accessedclients, office and financial analyst identifiers, names, householdnames, etc. The results of the search performed at field 608 may beshown at field 610. The user may select an existing client from field610, or in various embodiments, may select an entry allowing the user tocreate a new client. Data about existing clients may be stored, forexample, in plan database 118.

FIG. 3 shows the interface 600, according to various embodiments, withthe Select Household button 607 selected. The financial modeling tool100 may receive information regarding all members of the client'shousehold. Household members presently associated with the selectedclient's household may be listed at field 618. For example, in thenon-limiting embodiment shown in FIG. 3, the selected client's householdincludes the client, the client's spouse, and one dependent child.Selecting a particular household member from field 618 may enabledetailed information corresponding to the selected household member tobe entered and/or viewed at field 620. Additional household members maybe added, or existing household members deleted, using field 616 andadd/remove buttons 621, 623. Field 616 includes representations ofvarious kinds of household members including, for example, a client 622,a co-client 624 (e.g., a spouse) and a dependent 626. Selecting one ofthe representations 622, 624, 626 and then selecting the add button 621may add an instance of the selected type of household member to field618. Likewise, selecting a household member from field 618 and thenselecting the remove button 623 may remove that member from the selectedclient's household. Household members may also be added or removed fromthe client's household by selecting the appropriate icon and dragging itto or from field 618.

FIG. 4 shows the interface 600, according to various embodiments, withthe Select Scenario button 609 selected. The client may be listed atfield 630, and other members of the client's household may be listed atfield 632. The user may select a plan for the client from field 634. Thefield 634 may include representations of various pre-existing plans 636,637, which may be stored in database 118. The pre-existing plans may beplans generated for the client in an earlier session, or may be stock orexample plans. Pre-existing plans may be stored, for example, at plandatabase 118. The user may select a currently loaded plan (e.g., if aplan is currently loaded) by choosing icon 633. Selecting a pre-existingplan 636, 637 or currently loaded plan 633 from field 634 may causeadditional details of the plan to appear at plan preview field 638. Theadditional details may include the client's name, the other members ofthe client's household, the client's assets/liabilities, the client'sgoals, etc.

New plans may be generated by selecting one of the icons 631 and 635.The user may have the option to create and/or use a full plan byselecting icon 635 or an abbreviated plan by selecting icon 631. Asdescribed above, a full plan allows the user to enter detailed plan andassumption information about the client including the client's income,assets, liabilities, goals, etc. This information is then considered bythe simulation module 112 in generating a model of the client's futurefinancial condition. An abbreviated plan allows the user to enter lessdetailed financial information about the client, which may requiresubstantially less time and effort. In various embodiments, data for theabbreviated plan may be entered in a single user interface screen suchas, for example, user interface 300 shown in FIG. 5. The plan module 108and/or the simulation module 112 then considers this less detailedinformation and may estimate additional information needed to generatethe output. It will be appreciated that simulations run according tofull plans may generate more accurate results than those run accordingto abbreviated plans. Seeing an output generated according to anabbreviated plan, however, may encourage the client to complete a fulldetailed plan by showing the client the impact of more precise data onthe distribution of outputs.

FIG. 5 shows an embodiment of a user interface 300, according to variousembodiments, that may be provided to the user by the plan module 108 forreceiving an abbreviated plan. The interface 300 includes a field 302that allows the user to view and/or edit information relating to theclient's income, expenses, and assets. Income items entered may includepre-retirement earned income and post-retirement earned income. Also,various asset types and values may be viewed and/or edited at field 302,such as, for example, qualified and non-qualified assets. The interface300 also includes a real estate and mortgage field 304. The field 304may allow the user to view and/or edit information about the client'sreal estate and any mortgage or mortgages on the real estate. Additionalinstances of real estate may be added by selecting box 308. The client'sfinancial goals may be viewed and/or edited at field 306. Field 306shows two goals, 314 and 316. Each goal may include a goal type, a startdate, a duration, a minimum value, and a desirable value. The goals'type may be modified using drop-down window 313. Exemplary goal typesinclude home purchase, college education, pre-college education,wedding, major purchase, etc. Additional goals may be added by selectingbutton 310. When appropriate information is entered at fields 302, 304and 306, the user may select the Simulate button 312, causing thesimulation module 112 to generate a model based at least in part on theinformation entered at interface 300.

FIGS. 6-30 show embodiments of a user interface 700, according tovarious embodiments, that may be provided to the user according to theplan module 108 for receiving a full plan. Like the interface 600, theinterface 700 may include navigation toolbar 602 and navigation buttons612, 614 for allowing the user to navigate between various screens ofthe user interfaces. The interface 700 may also include navigationtoolbar 704 having buttons 705, 707, 709, 711, 713, 715, 717, 719, 721,with each button corresponding to one or more screens included in theuser interface 700.

FIG. 6 shows the interface 700, according to various embodiments, withthe Scenario Overview button 705 selected. Field 706 may allow the userto view and/or edit plan (e.g., scenario) details including, a planname, plan creation date, plan calculation date, etc. In variousembodiments, the user may also be able to edit other information atfield 706 including, for example, the loss tolerance of the client(e.g., the tolerance of the client for one year losses in theirinvestment portfolio). Field 708 may also allow the user to view and/oredit the client's address. In embodiments where the user is acting onbehalf of the client, a field 710 (shown in FIG. 6A) may listinformation about the user including, for example, their name and otheridentifying information (e.g., a financial analyst number, a branchnumber, etc.).

FIG. 7 shows the interface 700, according to various embodiments, withthe People button 707 selected. This screen may allow the user to viewand/or edit the members of the client's plan. The members of theclient's plan may, or may not, be identical to the members of theclient's household selected above with reference to interface 600.Referring back to FIG. 7, the current members of the client's plan maybe listed in field 714, with detailed information about the selectedplan member listed in field 716. Additional members may be added to theplan by selecting a member type from field 712 and using add/removebuttons 718 or by selecting the icon or representation of the membertype and dragging it to field 714. Also, a plan member may be removed byselecting the icon for the plan member in field 714 and using add/removebuttons 718 or dragging the icon from field 714.

FIGS. 8-12 shows the interface 700, according to various embodiments,with the Assets button 709 selected. Icons representative of the varioustypes of asset classes that may be held by the client are shown in field720. Field 720 shows exemplary classes including, non-qualified,qualified, real estate, and physical assets. It will be appreciated,though, that in other embodiments, different asset classes may be used.Each asset class may have an associated tab 724, 726, 728, 730 in field722. The user may access the tab by selecting it, or by selecting therepresentation of the associated asset class from field 720. Selectingthe applicable tab 724, 726, 278, 730 allows data about thecorresponding asset to be entered, as shown below.

In FIG. 8, field 722 is shown displaying tab 724, corresponding tofinancial non-qualified assets. Financial non-qualified assets mayinclude assets held in accounts that do not meet treasury coderequirements and therefore do not receive favorable tax treatment. Thetax treatment status of the assets may be used by the simulation module112 when generating the model. The user may view and/or enterinformation about specific non-qualified assets held by the client atfield 732. For example, the asset type, asset owner, purchase date,purchase price, market value, etc., may be shown. The user may add anadditional non-qualified asset by selecting the button 734 and enteringthe relevant information in field 732. In various non-limitingembodiments, the user may also add an additional non-qualified asset byselecting the non-qualified asset representation or icon from field 720.

FIG. 9 shows the field 722, according to various embodiments, with theFinancial Qualified Assets tab 726 selected. Financial qualified assetsare the opposite of non-qualified assets and may include assets held inaccounts that do meet treasury code requirements to receive favorabletax treatment, such as, for example, section 401k accounts, IndividualRetirement Accounts (IRA's), etc. In some jurisdictions, there may berestrictions on the liquidity of qualified assets prior to retirementwithout significant financial penalty. The user may enter and/or viewvarious information regarding financial qualified assets held by theclient at field 736. For example, the asset class, accountclassification, owner, and market value of each asset may be listed. Newfinancial qualified assets may be added by selecting the button 740and/or by selecting the icon of the financial qualified asset at field720.

FIG. 10 shows the field 722, according to various embodiments, with theReal Estate tab 728 selected. The user may enter and/or view variousinformation regarding real estate assets held by the client at fields744 and 746. Field 744 may include a representation of each real estateasset held by the client. Selecting the representation of a real estateasset shown at field 744 may allow detailed information about theselected asset to be shown and/or edited at field 746. The detailedinformation may include a description of the asset, the owner of theasset, the state where the asset is located, purchase informationregarding the asset, market value of the asset, and informationregarding any mortgages on the asset as shown in FIG. 10 and in moredetail in FIG. 11. Additional real estate assets may be added to orremoved from field 744 by selecting the representation of a real estateasset in field 720 and selecting the appropriate button from field 742.Again, this information, such as the mortgage amount, term and interestrate may be used by the simulation module 112 when it generates themodel of the client's future financial condition.

FIG. 12 shows the field 722, according to various embodiments, with thePhysical Asset tab 730 selected. The user may enter and/or view variousinformation about physical assets held by the client at fields 748 and750. The assets listed under tab 730 may be non-real estate physicalassets including, for example, cars, boats, jewelry, electronicequipment, etc. Representations of the physical assets owned by theclient may be listed at field 748. The user may add an asset to field748 by selecting the physical asset icon from field 720 and either usingadd/remove buttons 742, or dragging the icon to field 748. Doing so maycause field 751 to appear, as shown in FIG. 12A, allowing the user tochoose the appropriate class of a physical asset. Also, selecting aphysical asset representation from field 748 may allow detailedinformation regarding the asset to be reviewed and/or edited at field750. Again, physical assets may be removed from field 748 usingadd/remove button pair 742, or by selecting the icon of the appropriateasset from 748 and dragging it away.

FIGS. 13-15 show the interface 700, according to various embodiments,with the Income button 711 selected. Representations of the types ofincome that may be received by the client are shown in field 752.Non-limiting examples of income types include salary or earned income,non-salaried income, and qualified employer contributions. Fields 754and 764 may allow the user to view or edit additional information aboutexamples of each class of income. For example, each class of income mayhave an associated tab at field 754. Selecting the tab associated withan income class, or selecting the representation of the income classfrom field 752 may cause field 754 to list the currently entered incomesof the client.

In FIG. 13, fields 754 and 764 are shown, according to variousembodiments, with the Salary Income tab 758 selected. Representations oricons of the items of salary income directed to the client or othermembers of the client's household are shown at field 754. Selecting arepresentation may allow detailed information about the income to bedisplayed and/or edited at field 764. For example, owner, amount, startdate, end date, and growth rate options are shown at field 764.Additional items of salary income may be added to or removed from field754 by using the add/remove buttons 756 or by using the select and dragmethod discussed above. For example, the user may select therepresentation for salary from field 352 and drag it to field 754 or useadd remove buttons 756.

FIG. 14 shows the fields 754 and 764, according to various embodiments,with the non-salaried income tab 760 selected. Representations ofinstances of Non-Salaried Income directed to the client or other membersof the client's household are shown in field 754. Examples ofnon-salaried income may include social security, alimony, rent income,fixed annuities, child support, defined benefit pensions, etc. Selectingthe representation of an instance of non-salaried income from field 754may allow detailed information about the instance to be viewed and/oredited at field 764. Instances of non-salaried income may be added orremoved to field 754 using add/remove buttons 756.

FIG. 15 shows the fields 754 and 764, according to various embodiments,with the Qualified Employer Contributions tab 762 selected.Representations of qualified employer contributions directed to theclient or members of the client's household are listed at field 754.Selecting the representation of a particular instance may allow detailedinformation about the qualified employer contribution to be listed atfield 764. Exemplary detailed information may include the owner of theincome, the employee contribution required, the employer matchingpercentage and maximum contribution as well as whether and how much theemployee contribution and employer maximum contribution will grow. Forexample, the growth information may be entered at drop down field 765.The user may select various growth rates including, for example, theGlobal CPI rate, or no growth at all. Instances of qualified employercontributions may be added or removed using add/remove buttons 756, orby the selecting and dragging method described above. It will beappreciated that the user may not be able to enter or edit any instancesof qualified employer contributions unless the client owns qualifiedassets, for example, as described, at tab 726 of FIG. 9. Also, forexample, the qualified employer contribution data inputs may beconstrained by applicable regulatory provisions which may be stored, forexample, at regulation database 120.

FIG. 16 shows the interface 700, according to various embodiments, withthe Expenses button 713 selected. In the non-limiting embodiment shownin FIG. 16, the interface 700 is organized into a series of columns androws. An expense column 766 lists expense categories in a nested format.For example, clicking on the [+] icon next to a category may causesub-categories under the selected category to appear. Accordingly, theclient's expenses may be considered at a broad level, a detailedsub-category level, or a combination of both. Exemplary categoriesinclude, for example, Taxes, Pets, Lifestyle, Insurance Premiums,Household Food, Childcare, Auto, Additional Healthcare, etc.

For each category and sub-category listed in expense column 766corresponding entries may exist in the minimum amount column 768 and themaximum amount column 770. The user may list the minimum and maximumamounts that the client expects to spend on a particular category in itscorresponding entries in columns 768 and 770, respectively. In that way,the client's expenses can be bracketed between expected minimum andmaximum amounts. It will be appreciated that, in various embodiments,the user may forgo entering values for all sub-categories and mayinstead enter minimum and maximum amounts only for total annual expenses773, 775 and/or a portion of the categories.

Each of the columns 768 and 770 may include a respective Other item 769,771. The Other items 769, 771 may allow a user to categorize some, butnot all, of the client's expenses under one or more of the nestedcategories discussed above. For example, the Other items 769, 771 maydisplay the difference between the total annual expenses 773, 775 of theclient and the sum of the amounts classified in the respectivecategories. For example, referring to Other item 769, if the minimumamount of total household expenses is $25,000 and no other expenses arecategorized, then, the amount of the Other item 769 would be $25,000 sothat the total minimum annual expenses value 773 would remain at$50,000. As the sum of the categorized expenses increases (e.g., as moreexpenses are categorized), the value of the Other item 769 decreasesuntil the sum of the categorized expenses equals the total minimumannual expenses 773. At that point, if the sum of the categorizedexpenses were to increase further, the Other item 769 would remain atzero and the total expenses 773 would increase. It will be appreciatedthat the categorized expenses, Other item 771 and total maximum annualexpenses 775 of Maximum Amount column 770 may behave in a similarmanner.

FIGS. 17-18 show the interface 700, according to various embodiments,with the Loans button 715 selected. Representations of different classesof loans are listed in field 772. Example loan classes include mortgage,home equity, margin loans, qualified account loans, etc. Fields 776 and782 may show information about loans of different classes held by theclient. Field 776 may include tabs 778, 780, with each tab correspondingto one or more classes of loans. The user may access the tabs 778, 780by selecting them, by selecting a representation of a corresponding loanclass listed under the tab from field 772, or by selecting therepresentation of the corresponding loan class from field 772 anddragging it to field 776. As mentioned above, the amount, term, andrates of the client's various loans may be considered by the simulationmodule 112 in forecasting the client's future financial condition.

FIG. 17 shows fields 776 and 782, according to various embodiments, withthe Mortgages tab 778 selected. The field 776 includes representationsof mortgage-type loans held by the client. Selecting one of therepresentations of the mortgage-type loans in field 776 allows detailedinformation about the selected mortgage-type loan to be edited and/orviewed at field 782. For a mortgage-type loan, the detailed informationmay include the underlying property, the outstanding loan amount, themortgage type, the annual interest rate, the term, etc. One or moreadditional mortgages may be added to the field 776 by selecting themortgage representation from field 772 and using the add/remove buttons774, or selecting and dragging the representation to field 776. Amortgage may similarly be removed from field 772 by selecting therepresentation or icon of the mortgage to be removed and using theadd/remove buttons 774. In various embodiments, the field 776 may bepre-populated to include mortgages relating to real property described,for example, at tab 728 shown in FIG. 10.

FIG. 18 shows the fields 776 and 782, according to various embodiments,with the Other Loans tab 780 selected. The field 776 includesrepresentations of other, non-mortgage loans held by the client. Forexample, in FIG. 18, field 776 includes a home equity loan. Detailedinformation about a loan may be viewed and/or edited at field 782 byselecting the representation of the loan from field 776. Loans may beadded or removed from field 776, for example, in the manner describedabove with respect to tab 778. Some or all of the information relatingto the home equity loan may be pre-populated based on mortgages alreadyexisting on the client's real property.

FIG. 19 shows the interface 700, according to various embodiments, withthe Insurance button 717 selected. Field 784 includes representations ofexemplary classes of insurance. Indicators of insurance policiesactually held by the client are shown in field 785. Selecting one of theindicators in field 785 may allow detailed information regarding theselected policy to be viewed and/or edited at field 786. The type ofdetailed information may be dependent on the type of insurance policy.For example, detailed information for a health insurance policy mayinclude an insured party, and annual premium amount, a coverage amount,etc. Detailed information for a disability policy may include theinsured party, an annual premium amount, a premium growth rate, anannual disability payout, a payout growth rate, etc. It will beappreciated that policies may be added to or removed from field 785using add/remove buttons 783, or the select and drag methods describedabove. The premiums and potential payouts from insurance policies may beconsidered in forecasting the client's future financial condition.

FIGS. 20-22 show the interface 700, according to various embodiments,with the Goals button 719 selected. The user may use the screens shownin FIGS. 20-22 to view and/or edit financial goals of the client. Eachgoal may represent an expenditure or other financial event that theclient would like to achieve in the future. Field 788 includesrepresentations of potential goal types. For example, as shown in FIG.21, field 788 includes representations for college education goals,pre-college education goals, home purchase goals, major expense goals,major purchase goals, and wedding goals. Field 790 shows representationsof presently selected goals for the client. A goal may be added to field790 by selecting the representation of the desired goal type from field788 and using add/remove buttons 789, or by using the select and dragmethod described above.

Detailed information about current goals listed in field 790 may beviewed and/or edited at field 792 by selecting the representation of thegoal from field 790. For example, the start date and the minimum andmaximum costs of the goal may be entered and/or viewed. In variousembodiments, the goal may be assigned a priority. For example, usingslide-bar 795. The priority of the goal may be considered by thesimulation module 112 as described herein. The funding source for thegoal may also be viewed and/or edited, for example, by selecting button794. The priority and funding source or sources for a goal may beconsidered by the simulation module 112 when simulations are conducted.Selecting button 794 may cause field 796 to appear, as shown in FIG. 21.Field 796 may include a field 804 including representations of assetsavailable to the client to fund the goal, including loans. Selecting therepresentation of an asset or loan and actuating the add button 798causes a representation of the asset to appear in field 802. Thisindicates that the asset will be used to fund the selected goal.

If a loan is selected as an asset for funding a goal, the field 791 mayallow viewing and/or editing of detailed information about the loan, forexample, as shown in FIG. 22. Field 793 may include information aboutfixed rate portions of the loan or loans, if any, including, forexample, the annual interest rate, term, and repayment type. In variousembodiments, field 795 (shown in FIG. 22A) may include information aboutvariable rate portions of the loan or loans, if any, including, forexample, the interest rate, spread, reset period, term, and repaymenttype.

In addition to, or instead of, the funding sources designated at field796, it will be appreciated that the various simulations may implementan automatic funding hierarchy. For example, if there is not enoughcash-on-hand to fund a year's expenditures (e.g., consumption, goals,etc.), the simulation may apply a set of funding rules. The fundingrules may set forth a sequence for selling different types of assets andborrowing to finance expenditures. The funding rules may also specify apoint at which further expenditure is disallowed (e.g., when credit isexhausted, or a predetermined amount of assets have been sold).

FIGS. 23-30 show the interface 700, according to various embodiments,with the Assumptions button 721 selected. The assumptions that may beedited or displayed may be parameters to be considered by the simulationmodule 112 to simulate the client's financial condition as describedbelow. Data received through the interface 700 with the assumptionsbutton 721 selected may be stored, for example, at assumptions database116. As shown in FIG. 23, the interface includes a field 805 for viewingand/or editing various other assumptions. The field 805 may allowviewing and/or editing of various categories of assumptions. A categoryof assumptions may be selected from tab bar 804. It will be appreciatedthat various embodiments may omit some of the displayed assumptions, oradd additional assumptions. In that case, tab bar 804 may list more,fewer, or different kinds of tabs, for example, as shown in FIGS. 25-30.

FIG. 23 shows the field 805, according to various embodiments, with thePortfolio Loss Tolerance tab 806 selected, allowing the user to viewand/or edit the client's portfolio loss tolerance. The portfolio losstolerance may be an indication of how much risk the client is willing totolerate on their investment portfolio (e.g., a one year losstolerance), and may be dynamic over the client's life. For example, ayoung individual client may be willing to take more risk than an olderindividual client who is nearing retirement. In various embodiments, thesimulation module 112 may choose the assets that the client is assumedto buy and sell during the one or more simulated lives or businesscycles based on the client's portfolio risk tolerance. For example, thesimulation module 112 may choose a portfolio with a high concentrationof equities for a highly risk tolerant client, or a bond-heavy portfoliofor risk averse clients. In other various embodiments, the simulationmodule 112 may maintain a “fixed mix” asset allocation within a givenpercent (e.g., 5%) over the course of the client's life.

FIG. 24 shows the field 805, according to various embodiments, with theAsset Class Constraints tab 808 selected. The simulation module 112 mayselect the assets that the client is assumed to sell during thesimulations in order to pay for certain expenses (e.g., goals, long-termcare, etc.) based on the class constraints. In this way, the simulationmodule 112 can account for the asset allocation preferences of theclient. Field 805 may show a series of corresponding columns 823, 824,826. The column 823 lists asset classes that may be held by the client.The column 824 may include a row corresponding to each asset classlisted in column 823. Each row lists the minimum amount of thecorresponding asset class that the client wishes to hold as a percentageof the client's total portfolio. The column 826 may also include a rowcorresponding to each asset class listed in column 823. Each row incolumn 824 lists a maximum amount of the corresponding asset class thatthe client wishes to hold as a percentage of the client's totalportfolio.

FIG. 25 shows the field 805, according to various embodiments, with theBorrowing tab 810 selected. The simulation module 112 may makeassumptions as to whether and how much the client will borrow during thesimulations based on the information entered at borrowing tab 810. Thefield 805 may include various other fields 828, 830, 832 for receivingand/or editing various information relating to whether the client willutilize loans, and, if so, what kinds of loans will be used. Field 828allows the user to view and/or edit information regarding home equityloans. For example, the user may indicate whether home equity loans willbe allowed, which property will be the underlying property for homeequity loans, if allowed, and what interest rate will be assumed. Forexample, the interest rate may be entered as a base rate and spread.Field 830 allows the user to view and/or edit information regardingborrowing using margin loans. The user may indicate whether borrowing onmargin is allowed in the generated financial models, and what interestrate will be assumed, as well as the periods over which interest will becalculated and paid. Field 832 allows the user to view and/or editinformation regarding borrowing with qualified accounts. For example,the user may indicate whether borrowing with qualified accounts isallowed, and give an indication of what interest rate will be assumed.

FIG. 26 shows the field 805, according to various embodiments, with theManaged Account Fees tab 812 selected. The simulation module 112 maymake assumptions regarding whether the client will own managed accountshares during the simulations, and how much will be expended in doing sobased on the information entered at managed account fees tab 812. Thetab 812 allows the user to view and/or edit expected fees that will becharged to the client for managed accounts under the generated financialmodel. Default expenses may be stored, for example, at the assumptiondatabase 116. Column 834 lists asset classes. Column 836 may have a rowcorresponding to each of the asset classes listed in column 834. Eachentry into column 836 may represent the fees associated with managedaccounts including the corresponding asset class. As shown, the fees arelisted as a percentage annual cost; however, it will be appreciated thatany suitable measure may be used.

FIG. 27 shows the field 805, according to various embodiments, with theSalary Growth Rates tab 814 selected. The simulation module 112 mayalter (e.g., raise or decrease) the value of the client's salaries, forexample, as entered in tab 758 shown in FIG. 13, based on theassumptions entered at Salary Growth rate Tab 814. Default assumptionsregarding salary growth rates may be stored in database 116. Referringto the tab 814, the field 805 includes a chart 838 allowing salarygrowth rates over various age ranges, for example, of the client to beviewed and/or edited. For individual clients, the tool 100 may assume,for example, that salary growth rates will be larger early in life thanthey are later.

FIG. 28 shows the field 805, according to various embodiments, with theConsumption Adjustment Tab 816 selected. The simulation module 112 maymake adjustments to the client's household consumption during thesimulations based on the information entered at the ConsumptionAdjustment tab 816. Default consumption adjustments may be stored, forexample, at assumptions database 116. Fields 840 and 842 may allow theuser to view and/or edit the default adjustments that the generatedmodel will make to consumption in the event of contingencies. Forexample, field 840 lists the client's consumption during retirement as apercentage of previous consumption. Field 842 lists the consumption ofthe client's survivors, if the client were to pass away, as a percentageof previous consumption.

FIG. 29 shows the field 805, according to various embodiments, with theTax Assumptions tab 818 selected according to various embodiments. Thesimulation module 112 may model the client's tax liability for each yearincluded within a simulated time period (e.g., a life) based on theinformation entered at tab 818. Default assumptions regarding tax ratesmay be stored, for example, at assumptions database 116. With the tab818 selected, the field 805 may allow the user to alter the defaultassumptions regarding taxation frameworks that the client will besubject to over the simulations. For example, table 844 shows income taxbrackets and rates should the client file individually. Likewise, table846 shows income tax brackets and tax rates should the client filejointly. In various embodiments, assumptions about capital gains taxrates and structure (not shown) may also be included. It will beappreciated that different tax information may be required injurisdictions having other types of taxation in addition to, or insteadof income taxation. Also, it will be appreciated when the client is abusiness unit, different tax information such as, for example, corporaterates, will be included.

FIG. 30 shows the field 805, according to various embodiments, with theTransaction Cost tab 820 selected. Default transaction costs for buyingand selling securities may be stored, for example, at assumptionsdatabase 116. When the tab 820 is selected, the field 805 may allow theuser to view and/or edit the default transactions costs that will beconsidered by the simulation module 112 in generating the model. Column848 lists classes of assets that may be held by the client. Column 850includes an entry corresponding to each of the asset classes listed incolumn 848 that sets forth the cost of buying the asset. For example,the cost may be listed as a percentage of the purchase or a flat fee.Column 852 also includes an entry corresponding to each of the assetclasses listed in column 848. The entries in column 848 may indicate thecost of selling assets of the corresponding class. Again, the cost maybe listed as a percentage of the purchase, or as a flat fee.

FIG. 31 shows the interface 700, according to various embodiments,including a Simulation Option field 854. The simulation option field 854may allow the user to define parameters used by the financial modelingtool 100 to model the client's future financial conditions. For example,the number of simulations to be generated may be entered at field 856.In various embodiments, the default number of simulations may be 500. Itwill be appreciated that a minimum number of simulations, such as 500,may be required to generate a statistically robust result. Also, theeconomic world view over the forecasted time period may be entered atbox 858. The world view may represent the user and/or client'sassumptions about the general direction that the economy and marketswill take in the future. This may affect the values of financialvariables generated by the simulation module 112. Exemplary world viewsinclude bullish, bearish, and central. In other embodiments, differentview settings and/or a different number of simulations may be used.Selecting the button 860 may activate the simulation module 112, causingthe tool 100 to perform the simulations for the client.

FIGS. 32-46 show embodiments of the interface 900, according to variousembodiments, configured to display graphical results of the simulations.The interface 900 may include a display field 902, a goal field 906 anda details field 908. The display field 902 shows a graphicalrepresentation, and in particular, the topographical chart describedherein, representing the results of the model generated by thesimulation module 112. The display field 902 may be updated in real timewhile simulations are being run, or may appear only after allsimulations have been completed. Also, the display field 902 may displayresults for one financial output variable at a time, or the aggregate ofmultiple financial variables, and may be positioned on a pair of axes912 and 914 defining a plane. Axis 912 represents time, and axis 914represents the value of a financial variable or variables (e.g., networth).

The values of the financial variables versus time generated over thevarious simulations may be aggregated and plotted on axes 912, 914,resulting in topographical chart 918. Each coordinate set on the axes912, 914 corresponds to a point on the topographical chart 918. Theheight (or depth) of any particular point on the topographical chartindicates the number, or percentage, of simulations where the displayedfinancial variable (e.g., net worth) took the value and time (e.g., $1.5million in 2021) of the corresponding coordinate set on axes 912, 914.Thus, in one embodiment, peaks on the topographical chart 918 representoutcomes with relatively high probability and topographical points belowthe peaks (including valleys) represent outcomes with relatively lowerprobabilities.

The chart 918 may also be color coded, with the color of a plotted pointrepresenting the frequency of the occurrence of its correspondingcoordinate set. For example, the intensity of a color may indicate thefrequency of occurrence (e.g., the probability) of its correspondingcoordinate set. Points having colors that are more intense may haveoccurred in more simulations, while points having colors that are lessintense may have occurred in relatively fewer simulations. In variousembodiments, the color of points on the topographical chart 918 may alsoindicate the desirability (from the point of view of the client) of thecorresponding coordinate sets. For example, points on the topographicalchart 918 corresponding to undesirable coordinate sets (e.g., thoseindicating that the client lacks sufficient assets and/or income tomaintain desired consumption levels, etc.) may be assigned one color,such as red, while points corresponding to desirable coordinate sets maybe assigned another color, such as green or brown. It will beappreciated that this color coding may focus the client and/or user onthe downside risks they face, and the choices they have to mitigatethose risks. It will be appreciated that various shades of color or evenadditional colors may be used to illustrate gradations between degreesof desirability.

The legend 910 may allow the user to select which financial variable orvariables are displayed in topographical chart 918. For example, theuser may select a financial variable by actuating its correspondingbutton in legend 910. It will be appreciated that more than onefinancial variable at a time may be selected from legend 910 and viewedin field 902. In various embodiments, the legend 910 may be toggled onand off using Legend button 956. Also, the user may navigate thetopographical chart 918, for example, using navigation buttons 916. Bymaking the appropriate selection from buttons 916, the user maymanipulate the axes 912, 914 of topographical chart 918 to therebyacquire different views of the chart 918, for example, as shown in FIGS.33-35. Possible manipulations including, for example, lineartranslations, zoom in/out, rotation about multiple axes, andcombinations thereof.

The interface 900 may also include various tools for examining thetopographical chart 918. For example, a cursor 904 in FIG. 36 may beplaced at any point on the topographical chart 918. In this embodiment,the cursor 904 corresponds to a line intercepting a point on the timeaxis 912 or a band encompassing multiple points and therefore, a periodof time. FIG. 36 shows a state distribution window 926. In variousembodiments, the state distribution field may be displayed when the userselects button 952. The state distribution window 926 displays a summaryof the state of the client based on the calculated simulation outcomesat the time or period of time represented by the position of the cursor904. This summary may help explain the events (e.g., in terms ofsimulations outcomes or otherwise) that are causing the displayedtopographical outcome (e.g., the distribution of outcomes with respectto a particular variable or variables) at that time or period of time.For, example, the state distribution field 926 may show the numberand/or percentage of local simulations where the client is dead, inill-health, in long term care, in disability, and/or borrowing money atthe cursor location. Again, the state of the client in any particularsimulation may be determined based on input data stored, for example, inthe assumptions database 116 and may be considered in generating valuesfor the financial variables in a given simulation. The statedistribution field 926 may also show the volatility of the client'sportfolio over the simulations. In various embodiments, the interface900 also includes a monthly histogram field 928, shown in FIG. 37. Themonthly histogram field 928 may be displayed when the user selectsbutton 954, and may show a distribution of a selected financial variableover all simulations at a given cursor location (e.g., time). In otherwords, the histogram field 928 may display a time cross-section of thetopographical chart 918. Viewing the distribution of financial variablevalues in this way may help the user and/or client to understand theclient's likely financial condition and plan accordingly. For example,if the selected financial variable is asset return for some or all ofthe client's assets, knowing the likely distribution of asset returnsmay help the client develop an appropriate hedging strategy. Also, ifthe selected financial variable is client borrowing, then insight can beprovided regarding how much leverage risk the client is taking on. Thelocation of the cursor 904, designated by a month and year, is displayedat field 905.

The simulation module 112 may also compute a likelihood of the clientachieving desirable and acceptable levels of goal spend (e.g., theamount available to spend on a goal considering other goals andexpenses) and the expected distribution of goal spend outcomes. Thesuccess or failure of each goal may be indicated at display field 902.For example, a representation or icon for each goal may be positionedalong the time axis 912. The exemplary chart in FIG. 32 includes threegoal representations 920, 922 and 924. The representations may be placedat positions corresponding to the start date for the goals. In variousembodiments, each of the representations 920, 922, 924 may also includea number indicating the number and/or percentage of simulations in whichthe client achieves the respective goals. The representations 920, 922,924 may also, or alternatively, be colored to indicate the number and/orpercentage of simulations in which the client achieves the respectivegoals.

Selecting the representation 920, 922, 924 of a goal may causeadditional detailed information about the goal to be displayed, as shownin pop-up field 921 in FIG. 38. Pop-up field 921 may include additionaldetailed information about goal 920 including, for example, the averageamount that the client has available to spend on the selected goal inlight of expenses and other goals (e.g., goal spend) the goal'spriority, the goal's absolute minimum amount, the goals high-end targetamount, and the client's success rate with the goal. Additional detailedinformation about the selected goal, in this case goal 920, may also belisted at details field 908. The details field 908 may include a chart909, shown in more detail at FIG. 38A, that graphically displays theselected goal's absolute minimum amount 917, high-end target amount 919,and the distribution of amounts available for the goal over thesimulations 923.

It will be appreciated that details of the selected goal may be modifiedat details field 908 and/or pop-up field 921. Also, the time horizon ofthe goal may be moved by selecting the representation for the goal anddragging it along the time axis 912. Additional goals may be added tothe financial model, for example, by selecting a goal icon from field906 and/or by selecting and dragging an icon from field 906 to field902. It will be appreciated that different types of insurance, levels ofborrowing and changes to asset allocation may also be added to thefinancial model. In other words, the client and/or user can test theimplications of incurring different levels of risk in different ways(e.g., insuring or self insuring a risk; accepting a higher risk offailing to meet a goal versus taking more risk in the investmentportfolio, etc.). It will be appreciated that adding additional goals,or modifying details and/or the time horizon of the selected goal causesthe simulation module 112 to regenerate the simulations based on themodified goal. In that way, dynamic adjustments to the client's forecastcan be achieved by modifying a goal.

FIG. 39 shows an embodiment of the interface 900 with the retirementgoal 924 selected according to various embodiments. Pop-up field 925shows detailed information regarding the success rate of the retirementgoal. Success for the retirement goal may be measured by whether theclient has sufficient income and/or assets to maintain their desiredlevel of consumption after retirement. In various embodiments, thesuccess or failure of the retirement goal may be judged by dividing theclient's retirement into multiple bands. Each band may represent a blockof years during the client's retirement. For example, in the embodimentdepicted by FIG. 36, the client's retirement is divided into threebands, with the first band representing the first ten years ofretirement, the second band representing the second ten years ofretirement and the third band representing subsequent years ofretirement. The simulation module 112 may calculate a success rate foreach of the retirement bands, as well as a success rate for theretirement goal overall. If, during a simulation, the client has diedbefore the start of a band then that simulation may not be included inthe statistics for that band. If no lives live into a band then thatband is not included in the determination of retirement success. Thevarious bands of the retirement goal may also be shown on the planeformed by axes 912 and 914, for example, as bands 911, 913, 915. Thesuccess rate of each band may be indicated, for example, by its color.

It will be appreciated that the topographical chart 918 may beconfigured to display results for multiple financial variablessimultaneously, if desired. For example, FIG. 39A shows a representationof the client's net worth 919 and liquid assets 921. In variousembodiments, the financial variables displayed by the topographicalchart 918 may be selected from drop-down menu 901. Different financialvariables may be displayed in different colors. For example, in FIG.39A, net worth 919 is shown in shades of brown, while liquid assets 921are shown in shades of green.

In various embodiments, other chart types may be used in addition to orinstead of the topographical chart 918. For example, FIG. 40 shows thedisplay field 902 configured to display a line chart 927. The expectedaverage value of the selected financial variables and/or variable (basedon the simulation) at a point in time along the time axis 912 isindicated by the height (or depth) of the line chart 927. Also, FIG. 41shows the display field 902 configured to show a step chart 929. Theheight (or depth) of the step chart 929 at a position on the time axis912 may indicate the range (e.g., from maximum through minimum) ofvalues of the selected financial variable has over the varioussimulations. The color of the step chart 929 may indicate the likelihoodof values within the range. For example, the step chart 929 includes aline 931 indicating an average value for the displayed variable orvariables. A series of colored bands extend upward and downward from theline 931, with the color of each band indicating the number ofsimulations resulting in values of the displayed financial variable orvariables within the band. For example, in FIG. 41, bands with darkercolors represent values of the displayed financial variable that werereturned by relatively more of the simulations. FIG. 42 shows a stepchart 930 similar to the step chart 929, but having dark linesseparating the various colored bands. It will be appreciated that theresults of the various simulations may be displayed according to anysuitable graph or chart format.

The interface 900 may provide various additional options formanipulating the view and/or simulations. Referring to FIG. 32,selecting the Inflation Adjustment button 950 may cause the displayfield 902 to show results that are adjusted for the rate of inflation(i.e., the results may be displayed in constant or future dollars).Also, selecting Asset button 958 may cause a table of the client'sinitial assets to be displayed at an asset window 960 as shown in FIG.43. In addition, it will be appreciated that the user may be able tomake additional dynamic adjustments to the parameters and assumptionsunderlying the model of the client's financial condition. For example,the user may dynamically adjust the economic world view by selecting theworld state menu 962 from the view menu of the interface 900 as shown,for example, at FIG. 44. Also, the user may adjust assumptions regardingthe client or co-client's health by selecting health field 966 from theview menu of the interface 900, for example, as shown in FIG. 45. Theuser may also modify assumptions regarding the client's post-retirementconsumption using drop-down menu 968, shown in FIG. 46. It will beappreciated that dynamically adjusting a parameter or assumption maycause simulation module 112 to recalculate the various simulationsconsidering the modified parameter or assumption.

Embodiments of the present invention are also directed to apparatusesand methods for implementing a financial model. As described above, thefinancial model may generate a likely range of forecasted values of oneor more financial variables describing a client over a given time period(e.g., the life of a client, the life of the client's household, etc.).Executing the financial model may involve generating a number ofcomputer simulations of the time period. Each simulation may representone simulated life of the client and, in various embodiments, may alsoinclude a simulated life of a member or members of the client'shousehold, such as a spouse. For each simulated life, Monte Carlomethods may be used to estimate various health-related states of theclient and resulting values for the financial variables over the courseof the simulated life. The results of all simulated lives may beaggregated to generate an indication of the likelihood of various valuesof the financial variables into the future.

The financial model is described below as implemented by the computersystem 110 described above, including simulation module 112. It will beappreciated, however, that the financial model may also be implementedby any other suitable computer system. Also, the financial model, asdescribed below may receive input according to a user interface such asuser interfaces 300 and 600 described above, or according to any othersuitable user interface or interfaces. In addition, the financial modeldescribed below may present its output in the forms shown by userinterfaces 600, 900 described above, or according to any other suitableforms.

FIG. 47 shows a process flow 4700, according to various embodiments,illustrating a method of generating a simulated life of a client and/ormembers of a client's household. The simulation may be set to begin atany point in the simulated life, including at birth. For example, if aforty-five (45) year old client is the subject of the financial model,then the simulation may be configured to begin with the client aged 45years. At the outset of the simulation, the client may be assigned to afirst state, for example, by the simulation module 112 (4702). Inimplementations where members of the client's household are alsomodeled, they may also be assigned to a first state. FIG. 48 shows astate diagram 4800 showing several exemplary states including, forexample, a Healthy state 4802, a Long Term Care (LTC) state 4804, aDisabled state 4806, a Disabled in Long Term Care (Disabled in LTC)state 4810 and a Dead state 4808. The client may be initially assignedto one of the states 4802, 4804, 4806, 4808, 4810 based on user input.For example, if the client indicates that he or she is healthy, then heor she may initially be assigned to healthy state 4802.

The state of the client (and any modeled members of the client'shousehold) may be successively recalculated, with each recalculationrepresenting the passage of an interval or period of time in thesimulated life. For example, each recalculation may represent thepassage one month, one quarter, one year, etc. At each interval, thevalues of the financial variables may also be recalculated given theassets, income and expenses available to the client and considering theeffects of the new state on expenses and income. In this way, the stateof the client and its influence on the financial variables may beestimated at the various intervals throughout the simulated life. Steps4704, 4706, 4708, 4710 and 4712 below illustrate one exemplary method ofrecalculating the clients state and the client's financial variables.

The simulation module 112 may calculate the probabilities of the clienttransitioning from his or her current state to some or all of the otherallowable states (4704). According to the exemplary state diagram 4800and assuming that the client is currently in the Healthy state 4802,this may involve calculating probabilities that the client will remainin the Healthy state 4802, that client will transition from the Healthystate 4802 to the LTC state 4804; that the client will transition fromthe Healthy state 4802 to the Disabled state 4806 and that the clientwill transition from the Healthy state 4802 to the Dead state 4808. Inembodiments where other members of the client's household are alsomodeled, similar probabilities may also be found for these othermembers. Exemplary methods of calculating these probabilities for theclient and any household members are discussed in more detail below.

When the probabilities are calculated, the simulation module 112 mayrandomly select a new state for the client, based on the calculatedprobabilities (4706). For example, if the probability of the clienttransitioning from the healthy state 4802 to the LTC state 4804 is 10%,then there may be a 10% chance that the simulation module 112 willrandomly select the LTC state 4804 as the new state. Likewise, if thereis a 50% chance that the client will remain in the healthy state 4802,then there may be a 50% chance that the simulation module 112 mayrandomly select the healthy state 4802 as the new state. New states mayalso be found in a similar way for other modeled members of the client'shousehold, if any.

When a new state is determined for the client and for any other modeledmembers of the client's household, the simulation module 112 maycalculate the consequences of the new state and new interval to thefinancial variables. For example, the simulation module 112 maycalculate the client's income and assets given the new state and newinterval (4708). The client's assets may carry over from a previousinterval and may, according to various embodiments, be based on theassets provided as input to the financial model, as well as any assetsaccumulated during the simulated life due to interest, purchase, etc.

The client's income in the new interval may include any incomes from theclient's salary, the salary of other household members, investments,etc. According to various embodiments, new income may initially beassigned to a cash account. The client's new state as well as the newstates of any modeled household members may affect the amount of incomeavailable. For example, if the client, or the client's spouse, hastransitioned into a disabled state, such as LTC state 4804, Disabledstate 4806, or Disabled in LTC state 4810, then the affected party'sincome from salary may cease. In that case, provided that the client hasappropriate disability or long term care insurance, the salary may bereplaced with an insurance payment. If the client or client's householdmember has transitioned into the Dead state 4808, their income will alsocease, however life insurance, if available, will be payable to theclient's estate or surviving household members. Also, if the newinterval indicates the onset of retirement for the client, then theclient's salary income may cease and may be replaced with variouspension/Social Security income, depending on availability andeligibility.

The simulation module 112 may also calculate the client's expenses atthe new interval and state. According to various embodiments, expensesmay be classified according to an expense hierarchy includingdiscretionary and non-discretionary expenses. Non-discretionary expensesmay include, for example, taxes, minimum levels of basic expenses,health care expenses, insurance premium expenses, etc. The amount ofhealth care expense attributed to the client during each interval may bestochastically determined, for example, as described below. It will beappreciated that some non-discretionary expenses may depend on the newstate. For example, if the client or a member of the client's householdenters a disability state, such as LTC state 4804, Disabled state 4806or Disabled in LTC state 4810, additional expenses may be necessary tomaintain the client or household member. Discretionary expenses mayinclude, for example, contributions to retirement accounts (which may beclassified as discretionary or non-discretionary), contributions towardthe client's goals, basic expenses above minimum levels, and otherinvestments.

At each interval, the simulation module 112 may allocate the availableincome and assets to the new expenses. Income and assets may first beapplied to non-discretionary expenses, and then to discretionaryexpenses. According to various embodiments, the amount of availableincome and assets may be determined according to a funding hierarchy.The expense hierarchy and funding hierarchy may be utilized together tomatch income and assets to current expenses. Any suitable hierarchiescould be used. In one example, however, cash assets and current income(e.g., from the cash account) may be applied first to non-discretionaryexpenses. If any non-discretionary expenses remain then liquid assetsmay be utilized. If liquid assets are exhausted before non-discretionaryexpenses are met, then various loans may be used (e.g., home equityloans, mortgage loans, qualified account loans, etc.). Loans themselvesmay be prioritized according to any suitable method. Finally, ifnon-discretionary expenses are still not met, other measures may beimplemented, such as, for example, credit card financing, liquidating ofphysical assets, and liquidating qualified (e.g., retirement) accounts.

According to various embodiments, funding options above a given point onthe funding hierarchy may not be used to fund discretionary expenses.For example, although the simulation module 112 may simulate loans andasset liquidations to meet non-discretionary expenses, these fundingoptions may not be used to fund discretionary expenses. According tovarious embodiments, an exception to this general practice may exist forgoal funding. For example, the user may specify that certain types ofloans may be used to finance goals, as described above with respect toFIGS. 22 and 22A.

According to various embodiments, the simulation module 112 may allocateavailable funding amount different goals at different levels. Forexample, prior to the target date, the simulation module 112 may begin aset-aside fund for each goal, based on the minimum and desired spend ofthe goal as well as the amount of time remaining between the currentinterval and the desired start date of the goal. For example, duringeach relevant interval, each goal may be expensed at two differentlevels. A first minimum level may represent an amount necessary to allowthe client to meet a specified minimum goal spend. A second desirablelevel may represent an amount necessary to allow the client to meet adesired goal spend. Also, according to various embodiments, the user mayhave provided a priority for each goal, for example, as described abovewith respect to FIG. 20. The simulation module 112 may allocate anyfunds available for goal spending to the respective goal set-asideaccounts based on any suitable method. For example, the simulationmodule 112 may first fund all of the goal set-asides at the minimumlevel in order of priority. If available funds still remain, then thesimulation module 112 may allocate the remaining funds to raise thecontributions to the goal set-asides to the desired level, again inorder of goal priority.

According to various embodiments, the simulation module 112 may fundexpenses directly from the cash account. Under some circumstances, itmay be necessary for the simulation module 112 to rebalance the cashaccount. For example, if the cash account has a zero balance, thesimulation module 112 may rebalance the account, by taking loans,selling assets, etc., for example, as set forth in the fundinghierarchy. If all allowable loans and sales have been made, then thesimulation module 112 may institute a crisis funding process, wherelong-term physical assets may be liquidated, for example, at reducedvaluations. The cash account may also be rebalanced if its balanceexceeds a given threshold (e.g., $10,000) or a given proportion ofassets (e.g., if the cash account's forms a portion of total assets thatis shifted by more than 500 bps). In these cases, the simulation module112 may use the cash account funds to purchase assets according to anasset mix, which may be specified by the user or determined by thesimulation module 112.

As shown by the process flow 4700, steps 4704, 4706, 4708, 4710 and 4712may be continuously repeated until the client and all relevant membersof the client's household reach the Dead state 4808. According tovarious embodiments, the simulation may end upon the deaths of theclient and the client's spouse. Turning now to the exemplary statediagram 4800, the allowable states and state transitions will beexamined. The Healthy state 4802 may represent a state where the clientis in relatively good health. From the Healthy state 4802, fourtransitions are shown: 4850 to the LTC state 4804; 4852 to the Deadstate 4808; 4854 to the Disabled state 4806; and 4856 back to theHealthy state. Each of the paths 4852, 4854, 4856 may have an associatedprobability representing the likelihood that a client will move alongthe respective path. For example, path 4850 between the Healthy state4802 and the LTC state 4804 may be associated with the probability thatthe client will develop a need for long term care. The probabilities foreach path may be taken and/or derived from an actuarial table, forexample, as described below.

The LTC state 4804 may represent a state where the client is in need oflong term care. This may be due to an injury, illness, etc. According tothe exemplary state diagram 4800, a client in the LTC state 4804 ispermitted to transition to the Healthy state 4802 along path 4858, tothe Dead state along path 4860 or back to the LTC state 4804 along path4862. The Disabled state 4806 may represent a state where the client hassuffered a disability that prevents the client from working. From theDisabled state, the client may transition to the Disabled in LTC state4810 along path 4861, to the Dead state 4808 along path 4864 or back tothe Disabled state along path 4806. In the exemplary state diagram 4800,the Disabled state 4806 is assumed to permanent, hence no path isprovided from the disabled state 4806 to the healthy state 4802.

The Disabled in LTC state 4810 may represent a state where the client isboth disabled and in long term care. From the Disabled in LTC state4810, the client may transition to the Disabled state 4806 along path4868. In this case, the client may retain his or her disability, but mayno longer require long term care. Also, from the Disabled in LTC state4810, the client may transition to the Dead state 4808 along path 4872or back to the Disabled in LTC state along path 4870. In the exemplarystate diagram 4800, no transitions are allowed from the dead state 4808.

The exemplary state diagram 4800 shows just one set of allowable statesand state transitions. It will be appreciated, however, that theallowable states and state transitions may vary based on the parametersof the financial model. For example, FIG. 49 shows another exemplarystate diagram 4900 illustrating a financial model where an age of deathfor the client has been specified. Here, transitions to the Dead state4808 are not allowed, and all paths to the Dead state 4808 have beenomitted. In such a financial model, a simulated life may end when thesimulated age of the client reaches the predetermined age of death.

The probabilities of transitioning between the various states may betaken from actuarial data and/or relationships. For example, a mortalityrate may be used in determining the probability of progressing to theDead state 4808 (e.g., along paths 4852, 4860, 4864 or 4872). Accordingto various embodiments, the mortality rates used may be a function ofage, sex and health status, although it will be appreciated that moredependencies may be found and utilized if desired. For any given client,sex may be specified by the input data. Age may be an indication oftemporal position within the simulated life. The health status used tofind the mortality rate for any given client may be determined accordingto various methods. For example, it may be determined based on the stateof health reported by the client and may also depend on the clientsstate. For example, a client in the Disabled state 4806 may not exist inthe same state of health as a client in the Healthy state 4802.

According to various embodiments, a correction factor may be applied tothe mortality rate to adjust for increases in life expectancy that occurwith time. For example, a set of correction factors may be derived. Eachcorrection factor may correspond to an age of the client. The actualmortality rate may then be found, for example, according to Equation 1below:

M=M _(u)×(1−F)^(t)  (1)

In Equation 1, M represents the actual mortality rate; M_(u) representsthe unadjusted mortality rate, F represents the age-specific adjustmentfactor; and t represents length of time between the time at which themortality rate is being found and the present time.

A long term disability rate may be used in determining the probabilityof transitioning to the Disabled state 4806 (e.g., along path 4854).Like the mortality rates, the long term disability rate for any givenclient may be a function of various factors including, for example, theclient's age, sex and health status. Several long term care (LTC)related rates may be used in determining the probabilities of enteringand exiting LTC state 4804 and Disabled in LTC state 4810. For example,an LTC incidence rate may described the probability that a client willenter LTC state 4804 and/or Disabled in LTC state 4810. The LTCincidence rate may be a function of various factors including, forexample, marital status, age and health status. Other relevant LTCrelated rate is the LTC persistence rate and the LTC exit by death rate.The LTC persistence rate may describe the probability that a client inLTC will remain in LTC. This rate may be used to find the probabilitiesof transitioning along paths 4850 or 4862. According to variousembodiments, the LTC persistence rate may be a function of age and theduration of the client's stay in the LTC state 4810 or 4804. Forexample, a client who has been in LTC for an extended period of time maybe less likely to leave LTC. The LTC exit by death rate may describe thechance that when the client leaves an LTC state 4804 or 4810 by death,or returns to another state. The LTC exit by death rate may be used, forexample, in conjunction with the LTC persistence rate, to determine theprobabilities that a client will transition along paths 4860 or 4872.

As described above, morbidity, or the rate of healthcare spend, isanother expense that may be considered by the financial model. Accordingto various embodiments, morbidity may be characterized as a given amountof spend over a given period of time. This period of time may be chosento correspond to the state recalculation interval described above. Inthis way, incorporating morbidity into the financial model may involveadding the calculated morbidity to the total expenses for each interval.According to various embodiments, morbidity may be expressed as afunction of, for example, age, sex and health status. For example,morbidity may be represented as a set of health care spend levels, witheach level associated with a probability that a person of a given age,sex and health status would incur healthcare related expenses of up tothat level over the given period of time. The actual morbidity used atany given point in the financial model may be found by randomlyselecting a spend level, given a particular client. For example, ifactuarial data suggests that 1.08% of healthy males between the ages of45 and 49 should expect to incur monthly healthcare expenses of $905,then approximately 1.08% of all clients existing as healthy men aged46-49 would experience morbidity resulting in expenses of $905.

As used herein: the term, “client” refers to an individual or householdthat is the subject of a financial modeling tool; and the term, “user”refers to an operator of the financial modeling tool. In variousembodiments, the user may also be a client or an employee of a client.In other non-limiting embodiments, the user may be a financial advisorproviding advice to the client.

As used herein, “storing” when used in reference to a computer orcomputer system refers to any suitable type of storing operationincluding, for example, storing a value to memory, storing a value tocache memory, storing a value to a processor register, storing a valueto a non-volatile data storage device, etc.

As used herein, a “computer” or “computer system” may be, for exampleand without limitation, either alone or in combination, a personalcomputer (PC), server-based computer, main frame, server, microcomputer,minicomputer, laptop, games console, personal data assistant (PDA),cellular phone, pager, processor, including wireless and/or wirelinevarieties thereof, and/or any other computerized device capable ofconfiguration for processing data for standalone application and/or overa networked medium or media. Computers and computer systems disclosedherein may include operatively associated memory for storing certainsoftware applications used in obtaining, processing, storing and/orcommunicating data. It can be appreciated that such memory can beinternal, external, remote or local with respect to its operativelyassociated computer or computer system. Memory may also include anymeans for storing software or other instructions including, for exampleand without limitation, a hard disk, an optical disk, floppy disk, ROM(read only memory), RAM (random access memory), PROM (programmable ROM),EEPROM (extended erasable PROM), and/or other like computer-readablemedia.

The various modules 108, 112 of the system 110 may be implemented assoftware code to be executed by a processor(s) of the system 110 or anyother computer system using any type of suitable computer instructiontype. The software code may be stored as a series of instructions orcommands on a computer readable medium.

While several embodiments of the invention have been described, itshould be apparent that various modifications, alterations andadaptations to those embodiments may occur to persons skilled in the artwith the attainment of some or all of the advantages of the presentinvention. It is therefore intended to cover all such modifications,alterations and adaptations without departing from the scope and spiritof the present invention as defined by the appended claims.

1. A method for modeling financial variables describing a client over atime period, the method comprising: generating a first simulation of thetime period, wherein generating the first simulation comprises:assigning the client to a first health-related state; advancing thefirst simulation from a first interval of the time period to a secondinterval of the time period; calculating a first probability that theclient will transition from the first health-related state to a secondhealth-related state; randomly assigning the client to at least one ofthe first health-related state and the second health-related stateconsidering the first probability; calculating a client income for thesecond interval; and calculating a plurality of client expenses for thesecond interval. 2-32. (canceled)